Context

bumpver rewrites the version in pyproject.toml but not in uv.lock, so every release quietly desynced the two. That went unnoticed because nothing checked — until the uv-lock pre-commit hook landed (PLAT-2003), which now catches it as a red pre-commit on the next PR.

Six repos had already drifted this way; ratatosk's lock was three releases behind its pyproject. The repos that never drifted all turned out to have one thing in common: a pre_commit_hook on [tool.bumpver] that regenerates the lock as part of the bump commit. Correlation was exact — 10/10 repos with the hook in sync, 6/6 without it drifted.

Changes

• Add bin/bumpver-hook.sh (mode 100755) and wire it up as pre_commit_hook in [tool.bumpver], so the bump commit carries the regenerated lock:

#!/bin/bash
set -e
uv lock --no-upgrade
git add uv.lock

Scope / Non-goals

• --no-upgrade is deliberate and load-bearing. It reconciles the lock to pyproject.toml without pulling newer versions of anything else. A bare uv lock here would re-resolve everything and sweep in every dependency upgrade dependabot had written into pyproject but never locked — which is precisely how ratatosk picked up pydantic 2.13.4 and lost staging for a week (PLAT-2000).
• No dependency versions change in this PR. It only affects what future bump commits do.
• Existing lock drift, where present, is fixed separately — this stops the bleeding rather than backfilling.

Validation

• Matches the bin/bumpver-hook.sh already in use in auth-gateway, buyer-portal-service, card-issuing, checkout-api, fastapi-app-template, merchant-onboarding-service, njord-bank, orders and risk-engine.
• Script committed via the git data API so the 100755 exec bit is preserved.

Ticket

• https://linear.app/two-inc/issue/PLAT-2003

🤖 Generated with Claude Code

https://claude.ai/code/session_017VDJqb1XWoNNxZEfGQ8meH